1. Field
The embodiments discussed herein relate to building computing applications using metadata.
2. Description of the Related Art
A computer application is almost always a virtual representation of a physical or real world domain, presented to a user through a user interface. Interactions of the user with this virtual representation, through the user interface, result to the user effecting the virtual representation which some times may result to effects in the real world.
Consider the following example:
A user logs in to a web banking application, offered by her bank, accessible through a web browser. After logging in, the user clicks on the account number and sees the balance on the account and the recent transactions. The records displayed to the user, are the records of the real world account that the user opened at some point in the past. The user can select a specific transaction, say a “check paid” and the user can see additional information about the transaction or even an image of the cancelled check. This image is a virtual world representation of the actual physical check that the user wrote in the real world. The transaction record displayed in the browser is the virtual world equivalent of the transaction that actually took place in the physical world: e.g., a check was issued, the payee received the check, deposited the check to the payees account and eventually money was transferred to the payee account.
A user's interaction with the virtual representation of a physical world domain, through a user interface, to effect the physical world, can also be observed when a users books a ticket for airfare on the web, buys a book from a website, uses a desktop application to buy songs, or manages digital pictures, or talks to a customer service representative that handles an insurance claim.
In all of these cases a user interacts with a computer system application that has been created to enable specific actions within a well defined domain. The basic elements of such a computer system application are always the same.
FIG. 1 is a diagram of functional tiers or layers in a computer system application 50 in a computer 51. In FIG. 1, a typical computer system application creation involves creating a data model 52, application logic 54 and presentation logic 56, as follows: A data model 52, i.e., a virtual representation of a domain's objects referred to as domain model 52, is first conceived. In the case of the web banking application, these domain objects are accounts, customers, transactions, checks, and so on. The domain model 52 includes all relevant details of these objects and often some dependencies between them, i.e., every account number must have a customer associated with it. Often, but not always, the domain model 52 is represented in a database schema; the instances of these objects, e.g., a specific customer's information, are stored in a database. A database is usually taken to be a relational database management system (RDBMS) but a database can be any computational artifact that allows the permanent storage and retrieval of data. For example, a file in a file system can be used as a database. In practice, such systems often involve more than one “databases.” This layer of the computer system application can be referred to as the data layer 52.
The core of the application is the application logic layer 54. This is the computer executable code that executes the processes that the user interacts with through the user interface or the presentation layer 56. For example, whenever a users chooses to make a bill payment from within the web banking application, the code in the application layer 54 will execute a pre-defined process for executing bill payment. This process will receive the input from the user interface 56, such as who is the payee, the amount and the date, and then will check that funds are available, will perhaps recalculate the expected date of the payment, debit the customer's account for the amount being paid and so on. This process has been predefined by designers of the application 50 according to the requirements of the specific bank and the bank's real-world processes. Essentially, the application layer 54 executes a collection of pre-defined processes, some of them simple, some of them complex. Some of the processes might be data look-up and display processes, for example, whenever the customer selects an account number in the user interface 56, a process of the application logic 54 will retrieve the information for this account from the data layer 52 and display the information to the user via the presentation layer 56. Regardless of the complexity of the application layer 54 processes and of their nature (transactional versus informational), the application logic layer 54 is where these processes are defined and their execution takes place (or initiated). It is important to note that the processes that the application layer 54 of a specific application 50 is capable of encoding and executing are limited within the scope of the domain of the application layer 54, the domain being the data model 52. This is very important, because it means that extending the range of processes that can be executed in a specific domain of the application layer 54 requires that the domain model 52 needs to be similarly extended, which is not trivial. This layer of the system application can be referred to as the application layer 54.
Finally, the third layer of an application is the presentation layer 56, also commonly referred to as the user interface (UI). It is the UI that enables the users of the application 50 to interact with the processes of the application tier 54 and see the results of their actions.
This discussion can be summarized as follows. Users at the presentation tier 56 execute fixed (created at design time by developers) processes that are implemented at the application tier 54 and result in accessing or modifying data in the data storage tier 52.
Typically, adding functionality (new processes) has to be reflected in both application 54 and presentation tiers 56 and is limited by the domain model in the data tier 52. As a result, for example, integration of an application with other applications, or extending the application capabilities (processes the application can handle) is custom and expensive because of tight coupling between the application 104 and the data storage tier 52.
Further, creating applications has always been the domain of computer executable code developers. But the larger problem with the approach of using computer code developers is that there can be a disconnect between the users of computing infrastructure and the engineers that create the computing infrastructure. Specifically, a user thinks of information technology (IT) in terms of the things (tasks, actions) that the information technology enables the user to do, while engineers approach IT as an infrastructure that supports a variety of operations. In practice this means that building applications involves three tiers of actors, i.e., users, consultants (e.g., sales engineers, product managers), who interact with the users to formalize the kinds of functionality that users want to be made available to them, typically in the form of specifications of supported processes (such as business processes) and engineers, that translate these formalized requirements to functional specification and eventually into computer executable code. Moreover, building applications in this manner is an iterative process, as specifications, prototypes and implementations are continuously refined to better meet customers' needs and expectations. This approach suffers from two inherent limitations: (1) there is a disconnect between users and implementers both literally (physically), but also in terms of the conceptual language for understanding the system application and its functions (e.g., business objects vs. data records), and (2) resulting systems are limited to the set of functions that they were originally designed for, hence their extensibility is limited and costly.